The present invention relates generally to on-line transaction processing applications, and more particularly relates to managing non transactional resources or non-compliant transactional resources in transaction management systems for on-line transaction processing applications.
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or methods for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application typically maintains persistent data or xe2x80x9cstatexe2x80x9d of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations, such as in a database or other proprietary format data store.
Often, server applications require coordinating activities on multiple computers, by separate processes on one computer, and even within a sin process. For example, a money transfer operation in a banking application may involve updates to account information held in separate databases that reside on separate computers that may be geographically remote. Desirably, groups of activities that form parts of an operation are coordinated so as to take effect as a single indivisible unit of work, commonly referred to as a transaction. In many applications, performing sets of activities as a transaction becomes a business necessity. For example;, if only one account is updated in a money transfer operation due to a system failure, the bank in effect creates or destroys money.
A transaction is a collection of actions that conform to a set of properties (referred to as the xe2x80x9cACIDxe2x80x9d properties) which include atomicity, consistence isolation, and durability. Atomicity means that all activities in a transaction either take effect together as a unit, or all fail. Consistency means that after a transaction executes, the system is left in a stable or correct state (i.e., if giving effect to the activities in a transaction would not result in a correct stable state, the system is returned to its initial pre-transaction state). Isolation means the transaction is not affected by any other concurrently executing transactions (accesses by transactions to shared resources are serialized, and changes to shared resources are not visible outside the transaction until the transaction completes). Durability means that the effects of a transaction are permanent and survive system failures. For additional background information on transaction processing, see, inter alia, Jim Gray and Andreas Reuter, Transaction Processing Concepts, and Techniques, Morgan Kaufmann, 1993.
Prior patent applications also assigned to the assignee of the current invention (namely, Helland et al., xe2x80x9cAutomatic Transaction Processing Of Component-Based Server Applications,xe2x80x9d U.S. patent application Ser. No. 08/959,141; and Helland et al., xe2x80x9cDisabling And Enabling Transaction Committal In Transactional Application Components,xe2x80x9d U.S. patent application Ser. No. 08/959,142, both filed Oct. 28, 1997; which the present application hereby incorporates by reference and hereafter refers to collectively as the xe2x80x9cincorporated MTS Patent Applicationsxe2x80x9d) disclose an execution e,environment and platform for distributed server applications, which is embodied in the Microsoft Transaction Server (MTS) version 1.0 product. MTS provides a component-based framework or object model with system services to support transactions by potentially distributed groups of components of server applications under control of a transaction manager, such as the Microsoft Distributed Transaction Coordinator (MS DTC).
In the MTS, server applications use resource managers to maintain the durable state of the application, such as the record of inventory on hand, pending orders, and accounts receivable. Resource managers are a system service that manages durable data, such as may be contained in databases, durable message queues, file systems or other data storage resources. One example is the resource manager provided with the Microsoft SQL Server version 6.5. Resource managers operate in cooperation with the transaction manager to enforce the ACID properties on the durable data of the managed resource.
Resource managers are difficult to develop and implement for a particular resource (e.g., durable data store). This is because a resource manager deals with a number of the more complex issues in transaction processing. Specifically, the resource manager must properly interface with the transaction manager, and guarantee that all operations requested to be done by components on the managed resource adhere to the ACID transactional properties. The resource manager thus must ensure that all updates to the durable data by components that are completed under a specific transaction are made durable when the transaction commits, or are rolled back if the transaction aborts. The resource manager employs transaction-based synchronization protocols to isolate uncommitted work of active transactions. The resource manager also must ensure thread safety, which means the resource manager must be capable of being called by application components from any thread. The resource manager must further provide logging and recovery so that transactions involving the resource are durable over crashes and other failures (communications failures, process failures, and storage medium failures, as well as server system failures).
Further, an MTS Resource Manager (a resource manager that has been written to support MTS) must meet some additional requirements. In particular, an MTS Resource Manager implements all (or a substantial subset) of the xe2x80x9cOLE Transactionsxe2x80x9d interfaces, which allow integration into MTS and interface to the MS DTC. Additionally, an MTS Resource Manager must provide a resource dispenser (a service that provides pooling and automatic transaction enlistment for MTS server application components) for their managed resource. If there is no Resource Dispenser, then an alternative mechanism for automatic transaction enlistment must be provided.
Due to these difficulties, few resource managers are yet available for MTS (the Microsoft SQL Server version 6.5 previously mentioned being one example). However, a wide variety of resources with no transaction support are currently available on the market, and deployed in use. Further, there are a variety of resource managers (herein referred to as legacy resource managers) for other transactional systems that don""t provide the required interfaces (i.e., the OLE transactions interfaces) to interoperate in MTS, such as to interface to the MS DTC. For example, a number of travel industry reservations systems have reservations databases managed under the IBM CICS transactional system. It is therefore desirable to integrate such non-transactional resources and legacy resource managers into MTS more easily than implementing an MTS resource manager specific to each.
The present invention provides a form of resource management (herein referred to as xe2x80x9ccompensationxe2x80x9d or xe2x80x9ccompensating resource managementxe2x80x9d) that allows durable resources to be more easily integrated into a transactional system, and particularly into a component-based on-line transaction processing application environment such as MTS. In compensating resource management, a durable resource is integrated to participate in transactions under the transactional system by providing a compensating action to reverse each normal action performed on the resource gas part of a transaction. The normal action is persisted on the resource at the time of request. In a case where the transaction aborts, the compensating action is invoked outside of the transaction to return the durable resource to its pre-transaction state. For durability, information identifying the compensating action to be taken for each normal action performed during a transaction is written to a log on a write-ahead basis. Thus, in the case of a failure, recovery can be performed in accordance with the status of the transaction. in a component-based on-line transaction processing application environment such as MTS, compensating resource management can be provided for, a particular durable resource by implementing a compensating resource manager (CRM). In the CRM, a developer implements a compensating action for each normal action that the CRM supports on the durable resource. The developer also implements the CRM to perform write-ahead logging in connection with each normal action to specify the compensating action for that normal action.
In accordance with one embodiment of the invention illustrated herein (the illustrated embodiment), the CRM is developed as a pair of components, a CRM worker and a CRM compensator which share state (i.e., data) only through the medium of the log. The CRM worker performs the normal action at the time of request by a server application as a part of a transaction for the server application. This action and an interface through which the, action is accessed by the server application are specific to the particular CRM. When the server application invokes the normal action via the interface, the CRM worker also writes a log record to a system-provided log which identifies the CRM compensator.
The CRM compensator implements the compensating action corresponding to the CRM worker""s normal action. The CRM compensator that was designated by the CRM worker is later created to participate in later phases of the two phase commit protocol (e.g., Phase 1 and Phase 2) by taking appropriate further actions in relation to the normal action logged by the CRM worker. The CRM compensator supports a system-defined interface by which it receives two phase commit protocol notifications (e.g., prepare, commit and abort notifications) from the transaction manager (by way of a log recovery manager in the illustrated embodiment). These notifications allow the CRM compensator to participate in these phases of the two phase commit protocol.
More specifically, during the prepare phase, the CRM compensator can vote against committal of the transaction and force an abort in response to the prepare notification (e.g., by returning a value to vote xe2x80x9cNoxe2x80x9d in response to the prepare notification). The commit notification affords the CRM compensator an opportunity to perform clean-up processing after the normal action of the CRM worker. This clean-up processing is the removal of any state (durable or non-durable) that is being maintained for purposes of compensating for an aborted transaction. The commit notification also affords the compensator the opportunity to do any work that is irreversible. For example, in an ATM transaction, an account balance may be debited and cash dispensed. It is undesirable to dispense cash unless the debit is guaranteed to occur. With a CRM that manages the ATM, a CRM compensator would vote xe2x80x9cyesxe2x80x9d in response to a prepare notification as long as there is physically enough cash in the ATM. Then, in response to the commit notification, the CRM compensator causes the ATM to actually dispense the cash. In response to the abort notification, the CRM compensator performs the compensating action to reverse the CRM worker""s normal action. Accordingly, during normal processing of a transaction, the CRM compensator participates in the transaction prepare phase, and is notified of the transaction outcome. The CRM compensator can then clean up on commit, or compensate on abort. During recovery, on the other hand, the CRM compensator is again created and informed of the transactions outcome based on the log, allowing the CRM compensator to complete transaction processing (as appropriate) involving the resource as if there had net been a failure. For example, if Phase 1 was not complete before a system crash, the transaction is aborted and the CRM compensator is delivered an abort notification.
In the embodiment illustrated herein, each action (defined as the work done during a transaction, or set of log records) implemented by the CRM compensator, including particularly the compensating action, must be idempotent. This means that the CRM compensator""s action on a commit or abort of the transaction can be attempted any number of times, and if the action ever succeeds, the action achieves the same result as if the action had succeeded on its first attempt.